fix(seo): clear residual audit errors — squareup redirect + contact email (MARTECH-19 follow-up)#1012
Open
juan-arcadedev wants to merge 2 commits into
Open
fix(seo): clear residual audit errors — squareup redirect + contact email (MARTECH-19 follow-up)#1012juan-arcadedev wants to merge 2 commits into
juan-arcadedev wants to merge 2 commits into
Conversation
…t email Follow-up cleanup after the MARTECH-19 re-crawl (health 95, errors 143->39): - Redirect /:locale/references/auth-providers/squareup -> .../square. An external/stale link to the old "squareup" slug 404'd; this clears the "broken redirect" plus its 404/4XX rows. - The contact-us "Email Support" card now assembles its mailto after mount (mirrors <ContactEmail>), so SSR markup is a plain contact-page link and Cloudflare can't rewrite it into a broken /cdn-cgi/l/email-protection link. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
There was a problem hiding this comment.
Pull request overview
SEO follow-up cleanup to reduce residual audit errors by fixing a stale auth-provider URL and preventing Cloudflare email obfuscation from turning a mailto: into a broken crawled link.
Changes:
- Added a permanent redirect from the legacy
squareupauth-provider slug to the canonicalsquarepage. - Updated the Contact Us “Email Support” card to render a crawl-safe internal link on SSR and switch to a
mailto:only after client mount.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| next.config.ts | Adds a permanent redirect for /references/auth-providers/squareup (locale-prefixed) to the canonical square page. |
| app/en/resources/contact-us/contact-cards.tsx | Defers constructing the support mailto: until after hydration to avoid Cloudflare obfuscation producing broken crawled URLs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…ard) Mirrors the canonical guard added to ArcadeAI/www on the docs side. docs' only page-level canonical comes from the generated toolkit pages, so tests/integration-index-links.test.ts now asserts (re-deriving the canonical with the same pure helpers generateMetadata uses — readToolkitData + getToolkitSlug — to avoid importing browser-only render code): - every toolkit page's canonical points at its own URL (self-canonical), - canonicals are unique (no duplicate-canonical pages — the notion class MARTECH-19 fixed), - and none points at a redirect source or a non-generated route. The docs sitemap (app/sitemap.ts, static MDX only) is already guarded by tests/sitemap.test.ts (no redirect-source URLs, no duplicates). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Comment on lines
+284
to
+288
| for (const category of INTEGRATION_CATEGORIES) { | ||
| for (const { toolkitId } of await getToolkitStaticParamsForCategory( | ||
| category | ||
| )) { | ||
| const data = await readToolkitData(toolkitId); |
Comment on lines
+334
to
+347
| test("no toolkit canonical points at a redirect or a missing route", () => { | ||
| const offenders: string[] = []; | ||
| for (const { canonical } of canonicals) { | ||
| if (!canonical) { | ||
| continue; | ||
| } | ||
| if (redirectSources.has(toLocaleParam(canonical))) { | ||
| offenders.push(`${canonical}: redirect source`); | ||
| } else if (!validLinks.has(withEnLocale(canonical))) { | ||
| offenders.push(`${canonical}: not a generated route`); | ||
| } | ||
| } | ||
| expect(offenders).toEqual([]); | ||
| }); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Follow-up cleanup after the MARTECH-19 re-crawl (docs.arcade.dev health 81 → 95, errors 143 → 39 URLs). Clears two of the residual error rows that are fixable in-repo.
Related: MARTECH-19 (merged), MARTECH-17 (page-size, separate).
Changes
1. Stale
squareupauth-provider link → redirectThe crawl's "Broken redirect" + one of the 404/4XX rows is
/references/auth-providers/squareup→ 307 →/en/...squareup(404; the real page issquare). There's no internal link to it in the repo, so it's an external/stale backlink. Added a redirect/:locale/references/auth-providers/squareup → /:locale/references/auth-providers/square, which turns it into 308 → 200 and clears the broken-redirect + that 404/4XX.2. contact-us "Email Support" card → client-deferred mailto
contact-cards.tsxwas the last rawmailto:(the flagged MARTECH-19 follow-up). It now assembles themailto:after mount (same approach as<ContactEmail>), so the SSR/crawled markup is a plain/en/resources/contact-uslink and Cloudflare has nothing to rewrite into a broken/cdn-cgi/l/email-protectionlink.Deliberately NOT in this PR
pagerduty-api,notion) — these are transient data-churn artifacts, not a code bug:notiontoolkit.jsonis nowisHidden, andpagerdutyapi.json's category moved tocustomer-support, so the crawled…/development/pagerduty-apiand…/productivity/notionpages won't be generated by the current data. They self-heal on the next build/deploy + crawl. No code change made (forcing one would be fixing a non-bug).mongodb+srv://user:p@ss@host) and example addresses in guide code blocks. The only clean fix is the Cloudflare Email Obfuscation toggle, which we've decided not to flip; an in-repo workaround would mean mangling generated tool data / example code, which isn't worth it.